Introduction

I. Windows Hooks

The primary role of Windows hooks is to monitor the message traffic of some thread. In general, there are:

1. Local hooks, where you monitor the message traffic of any thread belonging to your process.
2. Remote hooks, which can be:
   1. thread-specific, to monitor the message traffic of a thread belonging to another process;
   2. system-wide, to monitor the message traffic for all threads currently running on the system.

If the hooked thread belongs to another process (cases 2a & 2b), your hook procedure must reside in a dynamic-link library (DLL). The system then maps the DLL containing the hook procedure into the address space of the hooked thread. Windows will map the entire DLL, not just the hook procedure. That is why Windows hooks can be used to inject code into another process's address space.

While I won't discuss hooks in this article further (take a look at the SetWindowHookEx API in MSDN for more details), let me give you two more hints that you won't find in the documentation, but might still be useful:

II. The CreateRemoteThread & LoadLibrary Technique

In general, any process can load a DLL dynamically by using the LoadLibrary API. But, how do we force an external process to call this function? The answer is CreateRemoteThread.

Let's take a look at the declaration of the LoadLibrary and FreeLibrary APIs first:

HINSTANCE LoadLibrary(
  LPCTSTR lpLibFileName   // address of filename of library module
);

BOOL FreeLibrary(
  HMODULE hLibModule      // handle to loaded library module
);

Now, compare them with the declaration of ThreadProc—the thread routine—passed to CreateRemoteThread:

DWORD WINAPI ThreadProc(
  LPVOID lpParameter   // thread data
);

As you can see, all functions use the same calling convention and all accept a 32-bit parameter. Also, the size of the returned value is the same. In other words: We may pass a pointer to LoadLibrary/FreeLibrary as the thread routine to CreateRemoteThread.

Interprocess Communications

Until now, we only talked about how to inject the DLL into the remote process. However, in most situations the injected DLL will need to communicate with your original application in some way (recall that the DLL is mapped into some remote process now, not to our local application!). Take our Password Spy: The DLL has to know the handle to the control that actually contains the password. Obviously, this value can't be hard-coded into it at compile time. Similarly, once the DLL gets the password, it has to send it back to our application so we can display it appropriately.

Fortunately, there are many ways to deal with this situation: File Mapping, WM_COPYDATA, the Clipboard, and the sometimes very handy #pragma data_seg, to name just a few. I won't describe these techniques here because they are all well documented either in MSDN (see Interprocess Communications) or in other tutorials. Anyway, I used solely the #pragma data_seg in the LibSpy example.

III. The CreateRemoteThread & WriteProcessMemory Technique

Another way to copy some code to another process's address space and then execute it in the context of this process involves the use of remote threads and the WriteProcessMemory API. Instead of writing a separate DLL, you copy the code to the remote process directly now—via WriteProcessMemory—and start its execution with CreateRemoteThread.

If you compare it to the declaration of CreateThread (MSDN), you will notice the following differences:

• The hProcess parameter is additional in CreateRemoteThread. It is the handle to the process in which the thread is to be created.
• The lpStartAddress parameter in CreateRemoteThread represents the starting address of the thread in the remote processes address space. The function must exist in the remote process, so we can't simply pass a pointer to the local ThreadFunc. We have to copy the code to the remote process first.
• Similarly, the data pointed to by lpParameter must exist in the remote process, so we have to copy it there, too.

Now, we can summarize this technique in the following steps:

1. Retrieve a HANDLE to the remote process (OpenProces).
2. Allocate memory in the remote process's address space for injected data (VirtualAllocEx).
3. Write a copy of the initialised INJDATA structure to the allocated memory (WriteProcessMemory).
4. Allocate memory in the remote process's address space for injected code.
5. Write a copy of ThreadFunc to the allocated memory.
6. Start the remote copy of ThreadFunc via CreateRemoteThread.
7. Wait until the remote thread terminates (WaitForSingleObject).
8. Retrieve the result from the remote process (ReadProcessMemory or GetExitCodeThread).
9. Free the memory allocated in Steps #2 and #4 (VirtualFreeEx).
10. Close the handles retrieved in Steps #6 and #1 (CloseHandle).

Additional caveats that ThreadFunc has to obey:

How to Subclass a Remote Control with This Technique

Let's explain something more complicated now: how to subclass a control belonging to another process with this technique.

First of all, note that you have to copy two functions to the remote process to accomplish this task:

1. ThreadFunc, which actually subclasses the control in the remote process via SetWindowLong, and
2. NewProc, the new window procedure of the subclassed control.

Solution 1

Observe the following picture:

Figure 2: The virtual address space

Note that INJDATA is placed immediately before NewProc in the remote process? This way NewProc knows the memory location of INJDATA in the remote processes address space at compile time. More precisely: It knows the address of INJDATA relative to its own location, but that's actually all we need. Now NewProc might look like this:

static LRESULT CALLBACK NewProc(
  HWND hwnd,       // handle to window
  UINT uMsg,       // message identifier
  WPARAM wParam,   // first message parameter
  LPARAM lParam )  // second message parameter
{
    INJDATA* pData = (INJDATA*) NewProc;  // pData points to
                                          // NewProc;
    pData--;              // now pData points to INJDATA;
                          // recall that INJDATA in the remote
                          // process is immediately before NewProc;

    //-----------------------------
    // subclassing code goes here
    // ........
    //-----------------------------

    // call original window procedure;
    // fnOldProc (returned by SetWindowLong) was initialised by
    // (the remote) ThreadFunc and stored in (the remote) INJDATA;
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

However, there is still a problem. Observe the first line:

INJDATA* pData = (INJDATA*) NewProc;

This way, a hard-coded value (the memory location of the original NewProc in our process) will be arranged to pData. That is not quite what we want: The memory location of the "current" copy of NewProc in the remote process, regardless of to what location it is (NewProc) actually moved. In other words, we would need some kind of a "this pointer."

While there is no way to solve this in C/C++, it can be done with inline assembly. Consider the modified NewProc:

static LRESULT CALLBACK NewProc(
  HWND hwnd,         // handle to window
  UINT uMsg,         // message identifier
  WPARAM wParam,     // first message parameter
  LPARAM lParam )    // second message parameter
{
    // calculate location of the INJDATA struct
    // (remember that INJDATA in the remote process
    // was placed immediately before NewProc)
    INJDATA* pData;
    _asm {
        call    dummy
dummy:
        pop     ecx     // <- ECX contains the current EIP
        sub     ecx, 9  // <- ECX contains the address of NewProc
        mov     pData, ecx
    }
    pData--;

    //-----------------------------
    // subclassing code goes here
    // ........
    //-----------------------------

    // call original window procedure
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

So, what's going on?
Virtually every processor has a special register that points to the memory location of the next instruction to be executed. That's the so-called instruction pointer, denoted EIP on 32-bit Intel and AMD processors. Because EIP is a special-purpose register, you can't access it programmatically as you can general purpose registers (EAX, EBX, etc). Put another way: There is no OpCode, with which you could address EIP and read or change its contents explicitly. However, EIP can still be changed (and is changed all the time) implicitly, by instructions such as JMP, CALL and RET. Let's, for example, explain how the subroutine CALL/RET mechanism works on 32-bit Intel and AMD processors:

When you call a subroutine (via CALL), the address of the subroutine is loaded into EIP. But, even before EIP is modified, its old value is automatically pushed onto the stack (for use later as a return instruction-pointer). At the end of a subroutine, the RET instruction automatically pops the top of the stack into EIP.

Now you know how EIP is modified via CALL and RET, but how to get its current value?
Well, remember that CALL pushes EIP onto the stack? So, in order to get its current value call a "dummy function" and pop the stack right thereafter. Let's explain the whole trick at our compiled NewProc:

 Address  OpCode&Params   Decoded instruction
--------------------------------------------------
:00401000 55              push ebp            ; entry point of
                                              ; NewProc
:00401001 8BEC            mov ebp, esp
:00401003 51              push ecx
:00401004 E800000000      call 00401009       ; *a*    call dummy
:00401009 59              pop ecx             ; *b*
:0040100A 83E909          sub ecx, 00000009   ; *c*
:0040100D 894DFC          mov [ebp-04], ecx   ; mov pData, ECX
:00401010 8B45FC          mov eax, [ebp-04]
:00401013 83E814          sub eax, 00000014   ; pData--;
.....
.....
:0040102D 8BE5            mov esp, ebp
:0040102F 5D              pop ebp
:00401030 C21000          ret 0010

1. A dummy function call; it just jumps to the next instruction and pushes EIP onto the stack.
2. Pop the stack into ECX. ECX then holds EIP; this is exactly the address of the "pop ECX" instruction as well.
3. Note that the "distance" between the entry point of NewProc and the "pop ECX" instruction is 9 bytes; thus, to calculate the address of NewProc, subtract 9 from ECX.

This way, NewProc can always calculate its own address, regardless of to what location it is actually moved! However, be aware that the distance between the entry point of NewProc and the "pop ECX" instruction might change as you change your compiler/linker options, and is thus different in release and debug builds, too. But, the point is that you still know the exact value at compile time:

1. First, compile your function.
2. Determine the correct distance with a disassembler.
3. Finally, recompile with the correct distance.

That's the solution used in InjectEx. InjectEx, similarly as HookInjEx, swaps the left and right mouse clicks for the Start button.

Solution 2

Placing INJDATA right before NewProc in the remote processes address space isn't the only way to solve our problem. Consider the following variant of NewProc:

static LRESULT CALLBACK NewProc(
  HWND hwnd,         // handle to window
  UINT uMsg,         // message identifier
  WPARAM wParam,     // first message parameter
  LPARAM lParam )    // second message parameter
{
    INJDATA* pData = 0xA0B0C0D0;    // a dummy value

    //-----------------------------
    // subclassing code goes here
    // ........
    //-----------------------------

    // call original window procedure
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

Here, 0xA0B0C0D0 is just a placeholder for the real (absolute!) address of INJDATA in the remote processes address space. Recall that you can't know this address at compile time. However, you do know the location of INJDATA in the remote process right after the call to VirtualAllocEx (for INJDATA) is made.

Our NewProc could compile into something like this:

 Address  OpCode&Params     Decoded instruction
--------------------------------------------------
:00401000 55                push ebp
:00401001 8BEC              mov ebp, esp
:00401003 C745FCD0C0B0A0    mov [ebp-04], A0B0C0D0
:0040100A ...
....
....
:0040102D 8BE5              mov esp, ebp
:0040102F 5D                pop ebp
:00401030 C21000            ret 0010

...thus, its compiled code (in hexadecimal) would be: 558BECC745FCD0C0B0A0......8BE55DC21000.

Now, you would proceed as follows:

1. Copy INJDATA, ThreadFunc and NewProc to the target process.
2. Change the code of NewProc, so that pData holds the real address of INJDATA.
   For example, let's say the address of INJDATA (the value returned by VirtualAllocEx) in the target process is 0x008a0000. Then you modify the code of NewProc as follows:

   558BECC745FCD0C0B0A0......8BE55DC21000	← original NewProc ¹
   558BECC745FC00008A00......8BE55DC21000	← modified NewProc with real address of INJDATA

   Put another way: You replace the dummy value A0B0C0D0 with the real address of INJDATA. ²
3. Start execution of the remote ThreadFunc, which in turn subclasses the control in the remote process.

² Some (bad) cracks modify the code of an executable in a similar way. However, once loaded into memory, a program can't change its own code (the code resides in the ".text" section of an executable, which is write protected). Still we could modify our remote NewProc, because it was previously copied to a peace of memory with PAGE_EXECUTE_READWRITE permission.

When to use the CreateRemoteThread & WriteProcessMemory technique

Some Final Words

At the end, let's summarize some facts we didn't mention so far:

1. Obviously you can't hook a thread that has no message queue. Also, SetWindowsHookEx won't work with system services, even if they link against USER32.DLL.
2. There is no CreateRemoteThread nor VirtualAllocEx on Win9x. (Actually, they can be emulated on Win9x, too; but that's a story for yet another day.)
3. All processes = All Win32 processes + csrss.exe
   Native applications (smss.exe, os2ss.exe, autochk.exe, etc) don't use Win32 APIs, and thus don't link against kernel32.dll either. The only exception is csrss.exe, the Win32 subsystem itself. It's a native application but some of its libraries (~winsrv.dll) require Win32 DLLs, including kernel32.dll.
4. If you want to inject code into system services (lsass.exe, services.exe, winlogon.exe, and so on) or into csrss.exe, set the privileges of your process to "SeDebugPrivilege" (AdjustTokenPrivileges) before opening a handle to the remote process (OpenProcess).

That's almost it. There is just one more thing that you should bear in mind: Your injected code can, especially if something is wrong with it, easily pull the target process down to oblivion with it. Just remember: Power comes with responsibility!

References:

Downloads

Article History